For release 5 (Rel5) of the 3GPP (Third Generation Partnership Program), as an enhancement to the pre-Rel5 shared channel concept, it has been agreed to add the so-called High Speed Downlink Packet Access (HSDPA) concept to the TiNTS (Universal Mobile Telecommunications System) Terrestrial Radio Access Network (UTRAN) architecture (illustrated in FIG. 1). The basic idea behind the HSDPA is to offer a shared high speed downlink (transport) channel (called HS-DSCH, for high-speed downlink shared channel) for use in communicating packet data to a UE (user equipment) device 18 (FIG. 1). As with the current DSCH, every UE device to which data can be transmitted on the HS-DSCH has an associated dedicated physical channel (DPCH). The DPCH is used to carry power control commands for the associated uplink, and if needed, other services, such as circuit-switched voice. The HS-DSCH offers a higher data rate and a fast retransmission mechanism, namely the HARQ (Hybrid Automatic Repeat Request) mechanism, provided by Node B 17 (FIG. 1). In pre-release 5 implementations, the only official shared channel in 3GPP in downlink is DSCH for which retransmission is always provided by the RLC (Radio Link Control) in the RNC (Radio Network Controller) 11 (FIG. 1) of UTRAN, which is relatively slow retransmission mechanism.
To support HSDPA (and especially HARQ), Rel5 of 3GPP defines a new MAC (Medium Access Control) entity, called MAChs (for MAC-high speed), located in Node B, as opposed to being located in the RNC, and more specifically in the RRC (Radio Resource Control) of the RNC, which is where all MAC entities capable of handling user plane data reside in UTRAN prior to Rel5. The MAC-hs exists at a Node B only when the Node B (i.e. the Node B cell) is configured to support HSDPA and is connected via the Iub interface to either MAC-c/sh (MAC-control/shared) or to MAC-d (MAC-dedicated), both of which are located in the RNC. The basic interfaces in UTRAN are indicated in FIG. 1. FIG. 2 illustrates MAC-hs in UTRAN per 3GPP Rel5, showing it connected to the MAC-c/sh through the Iub interface (and illustrating that the transport channel being used by MAC-hs is HS-DSCH, which corresponds in rel99 to the ordinary downlink shared channel DSCH transport channel). FIG. 3 illustrates the radio interface protocol architecture of HSDPA per Rel5, showing that the HS-DSCH FP (frame protocol) provides HS-DSCH FP data frames through the Iub interface. FIG. 4 illustrates the MAC architecture and MAC-c/sh detail on the UTRAN side, and FIG. 5 illustrates the MAC architecture and MAC-hs detail on the UTRAN side.
Due to the fact that as set out in Rel5, MAC-hs always resides only in Node B, and because Rel5 has Node B offering HARQ, Rel5 can be said to reorganize the functional split between Node B and RNC. In line with the reorganization, the scheduling/priority handling and the TFC (transport format combination) selection function (the task of selecting an appropriate transport format for control and user data) is assigned to Node B in Rel5, and so moved from RNC (either the serving RNC or the controlling RNC, if different from the serving RNC). As a result, final scheduling and data traffic control for HSDPA in Rel5 is not under RNC, but instead under Node B, as illustrated in FIGS. 4 and 5. (FIG. 4 shows that in MAC-c/sh (located in RNC), Scheduling/Priority Handling is provided for channels other than MAC-hs, such as PCH, FACH, and DSCH. FIG. 4 shows also that in MAC-c/sh, HSDPA data bypasses Scheduling/Priority Handling and is instead processed by the task indicated as Flow Control MAC-d MAC-hs, which provides it to MAC-hs. FIG. 5 shows Scheduling/Priority Handling for HSDPA located in MAC-hs, which is in Node B. Thus, the scheduling/Priority Handing for HSDPA is located in Node B in Rel5.)
Due to the functional reorganization and the new functionality (HARQ) in Node B, the pre-Rel5 3GPP application protocol procedures on Iub for DSCH setup and reconfiguration, in which the RNC allocated codes (of a code tree, allowing different users to use the same channel because different codes from the code tree make respective different communications orthogonal) to individual users (at radio link setup), cannot be used for HS-DSCH. The HS-DSCH provided by Rel5 corresponds to a shared channelization code resource, shared among the users primarily in the time domain; the code resource (and other resources) are provided to the Node B of a cell as a pool of cell-specific resources by the controlling RNC (CRNC) as (semi-static), and the Node B then allocates resources from the pool of cell-specific resources to individual UE devices in the cell (i.e. as user-specific resources). The cell-specific code resource consists of multiple codes of spreading factor 16. A part of the code tree is allocated for the HS-DSCH, while the remaining part is simultaneously used for other channels, e.g., dedicated channels used for speech services. Allocation by the Node B among the users of the shared code resource (and other resources), i.e. allocation by the Node B among the users of resources in the pool of cell-specific resources, is done on the basis of the 2 ms HS-DSCH TTI (Transmission Time Interval), and so is described here as being done dynamically as opposed to the semi-static allocation of the cell-specific resource pool by the CRNC for the Node B to use. The use of a short TTI allows for tracking fast fading, improves the granularity in the scheduling process, and reduced roundtrip delays. As mentioned, simultaneous transmission to multiple users is possible by using distinct parts of the codes allocated for HS-DSCH transmission, although the primary way of sharing the code resource is in the time domain.
Currently in 3GPP, two procedures can be considered for providing cell-specific parameters: cell setup/reconfiguration; and common transport channel setup/reconfiguration. Neither procedure is satisfactory, however, since both are intended for handling only truly static parameters. (These procedures are generally used only to configure a cell initially, not to later then change the parameters at all often, but only typically every few days or so, or even only as infrequently as monthly.)
The cell-specific HSDPA parameters are advantageously changed even as often as every 100 ms, and so existing NBAP (Node B Application Part) procedures are not adequate. Moreover, in case it is necessary to trigger a cell-specific HSDPA parameter reconfiguration according to an RNC algorithm (such as the RNC load-sharing algorithm, which can initiate the parameter reconfiguration), the existing procedures in NBAP are not suitable because the existing procedures (Cell Setup/Configuration and Common Transport Channel Setup/reconfiguration) are tied to the O&M (operation and maintenance) function and for these procedures to provide (changes to) cell-specific parameters would requires that they be adapted (changed). Moreover, as mentioned above, the existing procedures convey only static parameters, whereas HSDPA cell-specific parameters should be adjusted fairly often (though not at all as often as each TTI).
What is needed is a new Iub procedure for configuring and reconfiguring cell-specific parameters for a cell.